IBIS Macromodel Task Group
Meeting date: 10 October 2017
Members (asterisk for those attending):
ANSYS: Dan Dvorscak
* Curtis Clark
Broadcom (Avago): Xingdong Dai
Bob Miller
Cadence Design Systems: Ambrish Varma
Brad Brim
Kumar Keshavan
Ken Willis
eASIC: David Banas
Marc Kowalski
Ericsson: Anders Ekholm
GlobalFoundries: Steve Parker
IBM Luis Armenta
Trevor Timpane
Intel: Michael Mirmak
Keysight Technologies: Fangyi Rao
Radek Biernacki
Ming Yan
Maxim Integrated Products: Hassan Rafat
Mentor, A Siemens Business: John Angulo
* Arpad Muranyi
Micron Technology: * Randy Wolff
Justin Butterfield
SiSoft: * Walter Katz
Todd Westerhoff
Mike LaBonte
Synopsys: Rita Horner
Kevin Li
Teraspeed Consulting Group: Scott McMorrow
Teraspeed Labs: * Bob Ross
TI: Alfred Chong
The meeting was led by Arpad Muranyi. Curtis Clark took the minutes.
--------------------------------------------------------------------------------
Opens:
- Arpad noted that Bob will be at EPEPS next week (conference Monday through
Wednesday, IBIS Summit Wednesday). Arpad asked if we should cancel next
week's meeting. Bob noted that Radek was expected to be there too (unsure of
his status because of the wild fires in CA). No one else was known to be
attending. No decision was taken to cancel, but Arpad noted that we might
make that decision later and inform the list via email.
-------------
Review of ARs:
- None.
--------------------------
Call for patent disclosure:
- None.
-------------------------
Review of Meeting Minutes:
- Arpad: Does anyone have any comments or corrections? [none]
- Bob: Motion to approve the minutes.
- Walter: Second.
- Arpad: Anyone opposed? [none]
-------------
New Discussion:
Unused port terminations in BIRD 189:
- Arpad: Should we suspend this discussion since Radek can't be here?
- Walter: I don't want to neglect Radek's input, but I think we should review
Bob's latest suggestions.
- Bob: [sharing his Updated Unused_port_termination Rules email]
- Formal documentation of rules and their key points.
- Options "Open" or "Reference".
- Open - unterminated.
- Reference - effectively terminates with the reference impedance(s) of the
port(s) from the Touchstone file, with the idea that the unused ports are
actually to be removed (matrix reduction).
- The second point is that the EDA tool may allow the user to override these
options.
- The parameter is required, Open or Reference must be declared (note: the
parameter is only required if fewer ports are specified than are required
for the File_TS or File_TS0).
- Walter: I think you've written up the intent of what you wanted, and you
captured my impression of what the two of us agree on.
- One minor detail, for Open we may want to point out that tools can terminate
with a high impedance for stability. This is a minor point.
- My view of the difference between Radek and us:
- He wanted it to be optional and default to Open.
- He wanted two other options.
- I think we are all in agreement about the need for this parameter, but we
differ on the details (defaults, various options, etc.).
- I suggest that for the next draft version of the BIRD we insert the changes
as Bob as written them. This way it's in the document, but we know we are
leaving it an open issue as to whether we need to adopt changes proposed by
Radek.
- Bob: I agree. I don't care for Radek's suggestions. They venture into user
selection at that point, and it's way too complicated.
- Walter: We are in agreement, and we both understand Radek should have the
opportunity to review this and advance his proposals.
- Randy: Would it be helpful to include one more sentence to describe the option
of using an IBIS-ISS wrapper around the Touchstone file to provide
terminations? I believe Radek mentioned this as the best way for the
model maker to specify the per port impedances.
- Bob: I think it's self-evident.
- Randy: It's kind of a cookbook statement.
- Bob: I don't like that suggestion because it's a very inconvenient way to
allow matrix reduction. If you have an s100p, and you wrap it in a four
port IBIS-ISS subcircuit, then you have to provide 96 terminations in the
IBIS-ISS for the non-exposed ports. Then you'd have to do it again if
you wanted another 4 pins exposed. It's the same as not having an
unused_port_termination.
- Okay, I'll think about adding a sentence for this.
- I'll get this stuff into the next draft and then Radek can continue the
discussion.
C_comp improvements:
- Walter: I think where this is going to end up is that for an I/O, because of
the way resistors turn on and off, there are really going to be two
models, one for driving mode and one for receiving.
- I have a question for Randy. Is there a case when the clamping diodes are
different depending on whether the device is driving or receiving?
- Randy: I have seen some drivers where the driver circuitry is separated from
the pad by a transistor that you could use to switch out the driver,
while the receiver is always there on the pad. That's some older
technology designed to reduce the capacitance seen in Input mode.
- Walter: So are the ESD clamping diodes on the Rx side so they don't get
shut off?
- Randy: Yes, that's where they would be.
- Walter: Thanks, you've answered my question. I thought perhaps the driver
might have its own separate ESD devices.
- Randy: One thought there is that a driver transistor acts like a diode when
it's disabled.
- Walter: But then when it's disabled you're in receiver mode, and you have a
big resistor in between it and the receiver, right?
- Randy: Not necessarily, you could have an ESD specific diode that might be
on your pad, but also have some diode-type current that is from the
disabled driver structure.
- Usually if the driver's disabled and you sweep an I/V curve you see a
combination of these two.
- In practice, ESD devices often aren't modeled all that well as diodes.
- We sometimes have to replace the ESD model with a different diode or
transistor model to approximate the effects we see in measurements that
aren't replicated in the plain ESD models themselves.
- Bob: In general, for the model itself, you would use the same structure
whether it's driving or receiving.
- If there are fundamental I/V changes between driving mode and receiving
mode at the clamp level, IBIS can handle that with Submodels. These are
often used for on-die termination, but they could also be used to model
clamp variations.
- My understanding is that part of the C_comp proposal also includes something
that should not be modeled with clamp currents, though it could be, that
is a series resistance included when a buffer is a receiver. It's a
different phenomenon than would normally be modeled with clamp currents.
- Randy: I'm not sure how many people would want to include that in a C_comp
model, but a series resistance added as a sort of RC filter for the
input is a structure that exists for many input buffers.
- It is desirable for me to model that as part of a C_comp, but we haven't
heard many other people talk about whether they would use it.
- Walter: In that case, the clamping diode is on which side of that resistor?
- Randy: Typically it's still on the pad side.
- Walter: And we are turning that resistor on or off, or the R value changes
when driving or receiving?
- Randy: Think of it as the input buffer and the resistor are always there, in
driving or receiving mode. It's just interesting the look at the
signal passing through that resistor in input mode.
- Arpad: The driver doesn't drive through that resistor.
- Randy: Right, it would be a strange situation and we don't model that effect.
- Bob: You don't worry about filtering the driver, but the receiver gets a
filtered response.
- Randy: Right.
- Bob: If that resistor were part of a clamp circuitry you might have a double
counting effect if it showed up in the POWER_Clamp and GND_Clamp. That
could get tricky. In the new version we'd have a series RC instead.
- Since we're dealing with a receiver, we don't have issues with the K-table
extraction for a driver.
- Randy: Clamping currents, power and ground, are much less useful than they
used to be. With terminated buses you rarely have overshoot beyond the
voltage rails anymore.
BIRD 189:
- Arpad: We had a private email exchange amongst several of us related to
Interconnect modeling and how to group the various keywords and how to
eliminate the extra selections that might be need within Interconnect
Model Sets.
- Walter: I was suggesting that a Pin can't be in two different Models as a
victim.
- If you're doing a simulation and want to simulate certain pins as victims,
then the way we do it now is the user puts the package model in and has to
hook it up properly.
- We want to automate that. You want to find the model that has all the user
selected pins as victims.
- This is the case for Randy when he does an S-parameter for the DDR bus. He
generates a Touchstone file for all the pins on that bus. The EDA tool
could then look for the Model that has all the required pins as victims.
- Arpad: That would work if we assume that any lines designated as "aggressor
only" could only be used for crosstalk simulations. Currently the
BIRD doesn't prohibit doing a single-channel simulation with an
aggressor. As soon as we allow pins to appear multiple times as
aggressors, as you describe, we might still need a selection in that
case.
- Walter: As a practical matter, if someone is going to do something like
swathing:
- The model maker has a bunch of s6p crosstalk files (for a pin with two
adjacent aggressors).
- One s6p is for one as a victim, another is for a different one as the
victim. There are going to be multiple models with a given pin as an
aggressor. Would you ever have a case where a pin is an aggressor in two
different models but never a victim? If the model maker has gone through
the effort to make this configuration, why would a pin never be modeled as
a victim?
- Arpad: That's not the case I was concerned about.
- I'm worried if there are multiple models with the same pin as an aggressor,
and you only want to simulate that one pin.
- Walter: I think that would be poor style by the model maker to have a pin that
is an aggressor in multiple models, but is never a victim in a model.
- In that case, the user might have to make a choice, but the model maker can
fix that issue.
- Walter: If we follow my rule, any victim should have a model with its thru-
channel and all its aggressors.
- Bob: This is an Interconnect Model, essentially replacing packages.
- Many models will be issued without the optional "aggressor" tags.
- We know no [Interconnect Model] can describe the same pin twice (the
exception being the same pin can appear twice if you have the Set broken
up so that one Model handles the buffer to pad path, and another Model
handles the pad to pin path separately (so you need both to get the complete
path for that pin)).
- Within a Group, which makes reference to Sets, my proposed rule is that a
Pin's description should only appear once. I don't care about aggressors
or victims yet, I just care about documenting paths.
- The EDA tool can simulate which ones are aggressors and which ones are
victims and get coupled in contributions from wherever it wants.
- A fundamental requirement is that there is no selection necessary within a
Group.
- Walter: If you want a rule like that, you have to define it for a programmer
so they can confirm they can implement such a rule.
- Could you create a document that explains your rule and how the programmer
can implement it?
- Then we can debate whether we want to implement it.
- Bob: I will do that. I think my rule is simpler than the aggressor/victim
related rule.
- Arpad: I have a swathing question.
- Let's assume we have no issue with selecting the right Model Set.
- Say I'm modeling a diff pin pair with a neighbor aggressor on each side.
- I have an s8p. My main point is this has two victims. If you swath this,
how do you "slide it over"?
- Walter: I don't really swath it.
- Say I have 1 and 2 are the first diff pair, 3 and 4 the second, 5 and 6 the
third.
- Let's say in one model 3 and 4 are the victims, and 1 and 2 and 5 and 6 are
the aggressors. We have an s12p where the 4 "outside" pins are the
aggressors.
- There is another s12p for 3-4, 5-6, and 7-8, with 5 and 6 as the victims.
- I would create a second model (perhaps instantiating the same s12p) for the
3-4, 5-6, 7-8 case.
- Arpad: Okay, so it does shift (or slide) by the number of victims in the
middle. I was worried about only sliding over by one and having the
same pin appear as a victim in more than one Model.
- Bob: We are being sloppy with nomenclature.
- We are talking about "Models" as the whole thing.
- More precisely we should be talking about Groups and Sets.
- We may be in agreement, but just not using the same language.
- Walter: All I'm saying is ignore that no-repeats rule for pins labeled as
aggressors.
- Bob: You don't want the same pin path documented doubly in the same Group.
- If you want it repeated as an aggressor, put in a different Group.
- Arpad: Bob, you took the AR to write up your rules so we can study them.
- Walter: Motion to adjourn.
- Curtis: Second.
- Arpad: Thank you all for joining.
AR: Bob Ross to send out his proposed no-pin-duplication rules for BIRD189.
-------------
Next meeting: 17 October 2017 12:00pm PT
-------------
IBIS Interconnect SPICE Wish List:
1) Simulator directives